匈牙利命名法是過去的一種變數命名方式。簡單的說，藉由在變數的開頭加上一些字母的前綴，比方說是字串的 name 前面加上 str，變成 strName，來標註變數的形態（比方是字串），或者該特殊注意的地方（比方說，用 us 代表不安全字串）。

在過去，這可以讓維護的工程一看就知道這個變數的形態，或有哪些該特別注意的地方，是過去解決這些問題的一種設計方式。

到了現在，這個命名方式不僅用途不大，而且還可能造成後續維護的困擾。換句話說，非常符合我們建立難以維護專案的目的。

沒有什麼比起良好設計的匈牙利命名法，能更有效地殘害之後維護的工程師。如果我們在裡面，又時不時脫離原本匈牙利命名法設計的初衷，那效果就更好了。

以下技巧，可以保證你毀掉原本匈牙利命名法的初衷，為之後的工程師帶來無盡的痛苦：

常數

雖然 PHP 已經以大寫作常數的慣例，堅持使用 c 前綴代表常數。

例如，將

public const DUE_DATE = "02-28";

改成

public const c_duedate = "02-28";

類別

違背匈牙利命名法內，常用的變數應該要攜帶較少其他資訊的原則。

要達到這點，可以堅持每個類別都應該有自己的前綴。不讓別人提醒你針對什麼是類別這件事情，根本不存在匈牙利命名法前綴。

這個原則非常重要，如果沒有遵守，那程式碼可能會充斥許多簡短的，非常好唸的變數名稱。最差的狀況甚至可能導致整個混淆的努力失效，程式碼裡面出現用英文就可以看懂的段落！

比方，將

$user = User::find(1);
$post = Post::find(1);
public const UPDATE = 'update';

if ($user->can(UPDATE, $post)) {
    // 
}

改成

$suuser = User::find(1); // 第一個 s 代表 safe，u 代表這是一個 User 物件
$sppost = Post::find(1); // 第一個 s 代表 safe，p 代表這是一個 Post 物件
public const str_update = 'update'; // str 代表 字串
if ($suuser->can(str_update, $sppost)) {
    // 
}

m_

C++ 曾經有個命名慣例是使用 m_ 開頭的字代表成員（member）變數。

這個前綴可以幫助你區分儲存方法的變數，直到你想起方法（method）這個字也是 m 開頭。

o_apple

使用 o 或 obj 前綴代表所有物件（object），代表你有看到多型結構的大局。

包含所有資訊

堅持在匈牙利命名法綴詞裡面，包含所有獨立的資訊。

參考這個曾經真實出現過的變數名稱 a_crszkvc30LastNameCol。

花費一整個團隊的維護工程師大概三天的時間，才搞清楚這個變數是一個常數（c），參考（reference），函式的引數（a_），null 結尾字串（sz），某個資料庫欄位（Col）裡面名為 LastName 的資料，資料長度是 Varchar[30]（vc30），而且是某個表的 primary key 裡面的一部分（k）。

搭配「所有變數都是公開的」原則，這個技巧可以讓數千行程式碼直接廢掉！